1. Field of the Invention
The present invention pertains to multiplexed broadcast communications. More specifically, the present invention pertains to RDS broadcast control.
2. Discussion of Related Art
According to the present United States RBDS Standard of the National Radio Systems Committee (NRSC) dated Jan. 8, 1993 (The RDS Standard) Radio Data System (RDS) signals are a multiplexed data subcarrier on FM broadcast signals. The frequency of the subcarrier used by these RDS stations in the FM broadcast band is the third harmonic of the standard, nominally 19 khz, stereo pilot tone. The subcarrier is transmitted as a suppressed-carrier signal that is two-phase-shift-keyed (2 PSK) encoded to prevent audible interference with the operation of phase-locked-loop FM stereo decoders.
RDS data subcarriers are inaudible to radio listeners, providing supplemental visual displays and data services such as e-mail and paging to RDS-equipped radio receivers. The additional data that RDS stations broadcast on this subcarrier can increase their profitability by increasing the variety of broadcast services they provide and attracting additional listeners. Work on AM-band RDS standards for the United States is in progress.
RDS is potentially an important asset for both commercial and public broadcast channels. At the minimum, RDS facilitates tuning, improving travelers' ability to find related stations and similar program material as stations pass out of their receivers' range. RDS also simplifies channel selection for home-based receivers, as well as providing supplemental data services.
The RDS Standard breaks the data encoded on the RDS data subcarrier into 104-bit data segments called "groups". These segments are applied sequentially to the RDS subcarrier, without gaps, at a rate of about 686 code groups each minute. Segments containing different types of data have respective, specified code-group formats. The current United States NRSC Standard for RDS broadcasting defines 12 basic types of code-group formats.
Each data segment is a code group having four 26-bit code blocks. Each block contains a 16-bit information word followed by a 10-bit checkword that varies with an offset value that indicates the type and the location of that block within its group. Receivers apply the checkword to a particular binary matrix to assure decoder synchrony and verify the decoded data, preventing data communication errors.
All RDS code groups include a Program Identification block, a Program Type block and two variable data blocks. The Program Identification block contains a pi code that uniquely identifies the station. The Program Type block contains a Group Type Code and a Program Type Code (pty).
The Group Type Code, specifies what code format the receiver must use to interpret the code group. The pty code describes the station's audio program material. The pty code is used by RDS receivers to find a station broadcasting the type of audio program that the listener wants to hear: Sports, Talk, News, Top 40, Country, Jazz, Classical, etc. A pty code is selected by listeners, using whatever input means is provided by their RDS receivers, to automatically tune their radios to a desired type of program. The pty code only affects receiver tuning when the listener seeks another type of audio program.
Although the data broadcast by RDS stations changes from minute to minute and the pty code changes whenever the audio program material changes, the pi code is included in every code group and any change in the pi code causes RDS radio receivers to automatically tune out A minor coding error but an unacceptable risk, a major problem. Thus, manual coding of RDS data changes is not a practical option.
The most basic RDS group format, TYPE 0, is the format that supplies most of the automatic tuning and switching information to RDS receivers. Each TYPE 0 code group also includes alphanumeric character codes commonly used for displaying eight-character station or network logos on RDS receivers.
The TYPE 0 display characters are transmitted in pairs as an eight-bit Program Service (ps) code. The NRSC standard ps display is a sequence of four pairs of characters broadcast in four different TYPE 0 groups. Each pair in the sequence has a separate two-bit address code C1, C0 that indicates which character pair is in the given TYPE 0 group.
Each TYPE 0 group also includes a TA switch bit that indicates whether a traffic announcement is being broadcast. Receivers use the TA switch bit as an automatic station locator criterion. RDS-equipped receivers can also be set to interrupt a cassette or CD player when the receiver detects the TA switch bit, so that the driver can hear traffic information clearly, regardless of when it is broadcast. However, if there is a delay in restoring the TA switch bit to zero, listeners will tune out rather than let their cassette or CD players be idled by the station's programming error. This feature of RDS receivers is thus both a convenience and a complication that is a potential source of problems for RDS stations.
TYPE 2 groups supply "radiotext". Radiotext is a message, up to 64 characters long, that is displayed by some RDS receivers. The message may contain any supplemental alphanumeric information that the radio station wishes to have displayed, for example: artist and repetoire, phone numbers, etc. It is potentially a valuable listener service.
However, TYPE 2 code groups are only decoded and displayed by RDS receivers that fully comply with the NRSC standard, and compliance with NRSC receiver standards is voluntary in the United States. Thus TYPE 2 decoding has not been implemented on many less-expensive receivers. These non-compliant, stripped-down receivers reduce the value of RDS services to broadcasters and listeners alike, in that it prevents RDS stations from introducing their listeners to significant RDS services.
The radiotext problem is circular: 1) If listeners can only use RDS receivers for station selection, RDS will do little to increase a station's radio audience, or revenues. Few stations will invest in RDS equipment. 2) If few stations broadcast RDS services, an RDS receiver offers less benefit to travellers and other listeners, and fewer will buy RDS receivers. In the United States, in particular, RDS broadcasting is caught in this conundrum, and it undermines the health of the industry.
RDS requires advanced schedule management and code sequence control, far beyond the level required for audio program schedules, if the benefits of RDS are to be fully realized. In addition to the tuning and data displays noted above, RDS stations can provide numerous other kinds of data services, effectively simultaneously. TYPE 9 groups that produce channel-addressed or general voice-sampled emergency alert data, TYPE 3 navigational aid groups and the "transparent" data services: the in-house communications TYPE 6, and the leased data service TYPE 5 and paging service TYPES 1 and 7groups. The schedule management required for efficient encoding and time-division multiplexing of RDS data is, thus, orders of magnitude more complex than many broadcasters have dealt with heretofore.
Also, flexible code group sequencing is needed because the access and day-parting requirements for these additional RDS services are very diverse. RDS material such as traffic announcements and emergency warnings require immediate insertion into the broadcast signal, as well as higher group repetition rates to assure rapid detection by RDS receivers. RDS paging, on the other hand, requires that certain code groups be broadcast in an invariant time sequence. Furthermore, the volume of paging data and in-house and leased transparent data is likely to vary with time but these services are, preferrably, not time-limited. These additional data channels are, therefore, apt to overflow.
Attempting to superimpose these additional, highly variable and time-sensitive RDS data services onto pre-defined RDS schedules using scheduling routines developed for a station's audio programming, would push the station's RDS scheduling to the brink of collapse. Those routines lack the necessary editing, sequencing and encoding control capability. However, because RDS broadcast services are relatively new in this country, there is limited capital available for RDS projects. RDS systems must be compatible with existing capital equipment, as much as possible. Computer hardware already providing transmitter logging and control may also have the capacity to provide RDS data editing, sequencing and encoding in accordance with the present invention.